Aplicación de metodología ágil de almacenes de datos basada en el proceso unificado de desarrollo (página 2)

3.       RUP controla de forma
temprana el riesgo
técnico: muchos proyectos de
almacenes de
datos fallan por la confianza que brindan modelos
detallados creados de forma temprana. Si el modelo de
datos es muy
detallado, captura "la verdad única" y Usted a gastado
meses trabajando en este, el problema radica en que cualquier
arquitectura
funciona bien en el papel, hasta que usted no prueba la
arquitectura con código
no puede estar seguro de su
funcionamiento correcto.

4.       RUP controla el riesgo
financiero: el desarrollo
iterativo e incremental que de forma temprana maneja los
componentes críticos de un proyecto asegura
que se garantice el mayor valor de
funcionalidad primero, maximizando el retorno de la inversión todo el tiempo.

5.       RUP permite la agilidad
de forma disciplinada: los proyectos de almacenes de
datos son difíciles, se necesita flexibilidad pero al
mismo tiempo mantener un nivel de control para
lograr que el desarrollo sea efectivo.

El almacén de
datos es un aspecto muy importante en la infraestructura de
técnica de toda organización, debe ser visto como un
producto de
continuo desarrollo en el tiempo a través de una serie de
versiones. Cada una de estas versiones se considera un
proyecto.

Fases de Desarrollo

1. Fase de Concepción

En la etapa inicial de desarrollo (Concepción) se crean
las bases del proyecto. Se define el alcance, el plan inicial, la
visión del negocio con las metas y la justificación
del proyecto, estos artefactos (Stevens, 2000) son perfeccionados
a lo largo del desarrollo del proyecto. Los requerimientos
iniciales son capturados a través de casos de uso. Durante
esta etapa se comienza a pensar en la arquitectura inicial del
sistema (Stevens,
2000), desde el punto de vista del negocio y desde el punto de
visto técnico. Para un almacén de datos este
proceso
implica la creación de un modelo conceptual (Stevens,
2000) y un modelo de despliegue (Stevens, 2000), ambos a un alto
nivel en esta fase

Se define un plan para el proyecto a alto nivel (Stevens,
2000) y después se refina en un plan más detallado
en las siguientes iteraciones. El plan a alto nivel maneja las
dependencias principales y la estrategia
general, mientras que los planes más refinados
(correspondientes a iteraciones más detalladas) manejan
las tácticas propias de las situaciones en cuestión
de cada iteración. En la planificación del proyecto se debe tener en
cuenta acciones a
largo plazo como son las operaciones, el
soporte y la mejora continua al almacén de datos.

Esta fase de concepción finaliza asegurando la
existencia de un alcance definido, plan de desarrollo, análisis de riesgos
(Stevens, 2000) donde los clientes
concuerden con lo anterior y contar con una estrategia viable
para la construcción del almacén de
datos.

Existen algunos errores comunes que se incurre en esta etapa,
se debe evitar:

·        
Pensar que es una fase de determinación de los
requerimientos de forma tradicional.

·        
Pensar que se necesita contar con modelos y planes perfectos.

·        
Tratar de crear un modelo de datos completo al inicio del
proyecto.

2. Fase de Elaboración

El principal objetivo de
esta fase es mitigar el riesgo técnico en el proyecto para
ello se identifican los casos de uso que reflejan los riesgos
técnicos de alta prioridad, construyendo con los mismos un
esqueleto de trabajo del
sistema para probar la arquitectura propuesta, la cual se aprecia
en el diagrama de
despliegue. Para un proyecto de almacén de datos el riesgo
técnico se enfoca principalmente en el volumen de los
datos, acceso a los datos existentes anteriormente y calidad de los
datos.

Para realizar el trabajo es
necesario representar los casos de uso, en casos de uso
más pequeños donde los mismos representen
escenarios, de estos escenarios se seleccionan los que
representen mayor riesgo técnico. Durante esta fase se
crea el código necesario para probar la arquitectura. Es
necesario crear reportes elementales que utilicen estos datos, no
es factible implementar una lógica
compleja del negocio, pero se debe acceder a los datos
fundamentales de algún modo. Un criterio importante es
minimizar la documentación de forma tal que sólo
se cuente con la información que se utilizará.
También es necesario implementar el proceso de archivar
los datos antiguos y por último crear un reporte que
utilice tanto los datos activos en el
almacén de datos como los datos archivados.

Es útil en esta fase enlazar las entidades del negocio
del modelo conceptual con las bases de datos
fuentes de los
sistemas. Como se
implementará el código de extracción de
datos se deben adicionar atributos al modelo conceptual y se
deben enlazar estos con las columnas de las fuentes de datos,
sobre la base de just-in-time y sólo si provee valor al
proyecto. Continuamos trabajando con el modelo de requerimientos
identificando nuevos casos de uso a medida que los usuarios
lograr una mayor comprensión de lo que desean. Debemos
enfocarnos en los tipos de reportes y queries que utilizan los
clientes cuando realizan las actividades del negocio descritas en
los casos de uso. En esta fase solo se especifican los reportes y
sus problemas
críticos sin definir detalles, estos detalles se
especificarán a partir del principio just-in-time en la
fase de Construcción.

En la construcción del almacén de datos mucho
grupos de
trabajo presentan dificultades al tratar de lograr las mayores
especificaciones del problema de una sola vez, no tienen en
cuenta que las ideas del cliente cambian.
Es más importante menos documentación y más
trabajo sobre un software de alta
calidad.

Existen algunos errores comunes que se incurre en esta etapa,
se debe evitar:

·        
Documentación de requerimientos muy detallada.

·        
Documentación de diseño
muy detallada.

·        
Documentación detallada sobre las fuentes de datos.

·        
Documentación muy detallada sobre el enlace entre las
entidades del modelo conceptual y las fuentes de datos.

·         No
incorporar en el desarrollo del proyecto al personal
encargado de las operaciones y al personal cuya función es
el soporte.

Para terminar la fase de Elaboración se debe llevar a
cabo una revisión de los casos de uso del negocio,
determinando si tiene sentido construirlos a partir de una mejor
comprensión de la arquitectura y los requerimientos. Es
importante mostrar un esqueleto funcional de nuestro
almacén de datos que brinde al cliente nuestra
comprensión del problema y que al mismo tiempo permita
llegar a la conclusión que el proyecto supera los riesgos
fundamentales. Este esqueleto será el objetivo de trabajo
principal en la fase de Construcción. El objetivo
fundamental al final de cada fase de desarrollo es determinar si
se continúa o no con el proyecto, el proyecto del
almacén de datos debe tener sentido financiero y
técnico para continuar con su desarrollo.

3. Fase de Construcción

Durante la fase de Construcción el almacén de
datos se desarrolla de forma evolutiva completando el esqueleto
desarrollado en la fase de Elaboración. El sistema es
construido en iteraciones, cada iteración de
construcción representa un punto de chequeo donde se
analiza el cumplimiento de los requerimientos propios de la
iteración, trabajando de esta forma nos retroalimentamos
de los clientes de forma periódica, incrementando la
posibilidad de entender sus necesidades actuales. Además
produciendo software actualizado de forma regular brindamos
evidencias
concretas a nuestros clientes de realizar avances en el
desarrollo del proyecto. Durante cada iteración se trabaja
en los requerimientos de más alta prioridad de forma
sucesiva.

Necesitamos adoptar algunas técnicas
de desarrollo evolutivo como son:

·        
Gestión
de configuración: el objetivo principal es gestionar los
artefactos generados en cada ciclo de vida
del proyecto.

·        
Integración continua: el objetivo principal
es reconstruir el sistema en cualquier momento que algo
cambie.

·        
Refactorización: un simple cambio en el
código fuente, el cual mejora el diseño, no debe
implicar que algo funcione mal o que sea necesario adicionar
otras cosas.

·        
Prueba de regresión: asegura que los cambios hechos al
sistema no rompen funcionalidades existentes.

Para desarrollar cada caso de uso en esta fase la estrategia
es similar:

1.            
Identificar los elementos de datos requeridos.

2.            
Para cada elemento identificado en 1, determinar su mejor
fuente.

3.          El
esquema de datos del almacén de datos debe aceptar nueva
información (tablas y/o columnas).

4.            
Desarrollar el código de extracción,
transformación/limpieza (si es necesaria) y carga del
almacén de datos y de esta forma detectar datos
necesarios.

5.            
Confeccionar los reportes requeridos.

6.            
Aplicar pruebas de
regresión en base al enfoque evolutivo.

7.            
Retroalimentarse del cliente mostrándole cualquier cambio
realizado.

8.            
Iterar.

Es importante identificar algunos aspectos importantes sobre
la fuente de datos:

·              
Disponibilidad de la información (24/7).

·              
Medio de acceso (red, cinta, dvd).

·              
Acceso a los datos (vía SQL,
vía Web
Services).

·              
Personal de contacto para esa fuente de datos.

·              
Derechos de
seguridad de
acceso.

·              
Estructura del
dato.

Desde el punto de vista de la importancia de los modelos,
estos pueden ser organizados en el siguiente orden:

1.            
Modelo de datos físico.

2.            
Modelo de casos de uso.

3.            
Modelo de enlace entre la fuente y el destino.

4.            
Modelo de datos lógico.

Existen algunos errores comunes que se incurre en esta fase,
se debe evitar:

·              
Enfoque intensivo a datos, en vez de enfocarnos al dato
enfocarnos en el uso de los datos.

·              
Organizar el trabajo por fuente de datos.

·              
Escribir especificaciones de reporte de forma detallada.

·              
Herramientas
no adecuadas.

·              
Pobre colaboración con los clientes.

·              
Pobre colaboración con el personal de la fuente de
datos.

La fase de Construcción termina con la revisión
de las capacidades operacionales iniciales. El principal objetivo
de esta revisión es comprobar que el almacén de
datos puede continuar hacia la siguiente fase
(Transición), que los clientes puedan asumir el despliegue
del almacén de datos y que los casos de negocios
mantengan su sentido.

4. Fase de Transición

El objetivo principal de esta fase es el despliegue de forma
productiva del almacén de datos, para ello es necesario
comunicarle el plan de despliegue a los clientes finales. Puede
ser realizado a través de correos, presentaciones o
entrenamientos. Durante la primera versión productiva del
almacén de datos es necesario el entrenamiento a
los usuarios pues no están familiarizados con las
herramientas de análisis de la información, en
siguientes versiones no es necesario este entrenamiento sino
el
conocimiento de los nuevos datos que pueden ser accedidos o
las modificaciones realizadas en otros datos.

En esta fase se deben realizar las pruebas del sistema y la
aceptación final, pero si esto se ha realizado en las
fases de elaboración y construcción, aquí se
convierte en un procedimiento
formal. El error más común en esta fase es pensar
que es una fase de pruebas. Aquí comienza la etapa de
desarrollo de versiones.

Podemos resumir que los artefactos elaborados en las
diferentes fases son los siguientes:

Fase de Concepción:

·         Plan
del proyecto.

·        
Visión.

·         Casos
de Uso.

·        
Diagrama Conceptual.

·        
Diagrama de Despliegue.

·         Acta
de aprobación con el Cliente.

Fase de Elaboración

·        
Esqueleto de trabajo con los casos de usos más
importantes.

·        
Modelo de enlace entre la fuente y el destino.

·        
Reportes elementales.

·         Acta
de aprobación con el cliente.

Fase de Construcción

·        
Desarrollo evolutivo del esqueleto de trabajo.

·         Acta
de aprobación con el cliente.

Fase de Transición

·         Plan
de despliegue.

·         Acta
de las pruebas del sistema y la aceptación final por el
cliente.

Hemos expuesto ideas útiles con relación al
diseño e implementación de un almacén de
datos, un elemento indispensable actualmente en nuestros
ambientes empresariales.

Referencias

1.  Casares, C. (2003). Data
Warehousing. [En línea]. Disponible en: .

2.  Scott
W. A. (2006). Practice Leader, Agile Development, Rational
Methods Group, IBM. [En línea]. Disponible en:
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0506gong/

3.       Stevens,
Perdita. Ed. 2000. Software Engineering with Object and
Components.

Autores

Lic. Carlos Galindo González

División Centro – TRD Caribe, Cuba, Santa
Clara

Dr. Ramiro Pérez Vázquez

Universidad Central de Las Villa, Cuba